kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/newsgroups/misc.19980424-19980901/000122_news@newsmaster….columbia.edu _Sat May 23 20:12:34 1998.msg

Internet Message Format | 1998-08-31 | 6KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id UAA08167
    for <[e-mail]>; Sat, 23 May 1998 20:12:30 -0400 (EDT)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id UAA06886
    for kermit.misc@watsun; Sat, 23 May 1998 20:12:30 -0400 (EDT)
Path: news.columbia.edu!panix!news-peer.gip.net!news.gsl.net!gip.net!ais.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!news.iastate.edu!vax1.miu.edu!JHMEYERS
From: [e-mail] (John H Meyers)
Newsgroups: comp.protocols.kermit.misc,comp.sys.hp48
Subject: Re: Kermit on the HP48 (Was: One-Way Transfer)
Date: 24 May 1998 00:06:37 GMT
Organization: MIU Computer Services,  Fairfield, IA 52557.  Not Approved.
Lines: 90
Message-ID: <6k7oad$5ka$[e-mail]>
References: <[e-mail]> <[e-mail]> <6k42pd$a3m$[e-mail]> <[e-mail]> <6k4ef6$g6p$[e-mail]>,<[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: vax1.mum.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:8777 comp.sys.hp48:81375

As to the flow-control debate (Xon/Xoff vs. none) with HP48 Kermit,
I do not see how it could possibly hurt to leave it set to Xon/Xoff,
unless "control-character prefixing" were inadvertently
disabled even for Xon/Xoff, since in the absence of a buffer
actually becoming filled to the specified point, no Xoff will
get sent and no time will be wasted; however, not many people
are likely to have enabled Xon/Xoff flow control within
the HP48 itself, since to do so requires manually editing
the IOPAR variable in the HOME directory per directions
in the manual, which no one ever reads anyway :)

Being a conservative person, I always enable Xon/Xoff
flow control on both sides, just in case the theoretical
argument that it's impossible to trigger the condition
should ever fail on either side, which certainly would
cause a problem if it did, especially if the elected
block-check-type was minimal or none on either side.

People tend to forget that even "official" Kermit
"negotiates down" the "block check" option to the lesser of
what both sides propose, and that non-official implementations
of Kermit in various "terminal emulators" generally never even
state or give the user any option for choosing block checking;
at least the HP48 gives the user a choice (unfortunately defaulting
to 1, rather than 3, much as flow-control defaults to none).

The HP48 does support block-check-type 3, however, as it has
the same CRC algorithm built into its hardware.

As to parsing of ascii, the HP48 Kermit implementation embeds
two extra services not normally considered part of Kermit;
if the HP48 is told to send in "ascii mode," it both "decompiles"
(translates an internal binary object into ascii words) and translates
some or all of the ascii characters having decimal value 128-255
into "backslash-prefixed" codes (some digraphs, some numeric codes);
carriage-returns may also be inserted before linefeeds as this occurs.

Conversely, if the HP48 is told to receive in "ascii mode,"
it performs character translation (backslash-prefixed codes
into single characters) and then also "compiles" on the fly
(translating text words into binary internal objects), in which case
any syntax error terminates the transfer immediately (thus compiling
is performed per packet, rather than after receipt of the entire file).

When sending in "binary mode," no translation occurs, and no
slowdown occurs.  When receiving in "binary" mode, the entire
file is received as a string; however, the appending of each
new packet to the string, copying the entire received string each time,
is what causes the slowdown (every now and then it may suddenly revert
to the original speed, perhaps after storing a large chunk of the
received string, or else after an internal "garbage collection").

I do not know for sure, but if the internal 256-byte default
HP48 I/O buffer is a fixed area, then no "garbage collection"
(or other processing) ought to be required in the middle of a packet;
otherwise one would expect to see more re-transmissions, especially
with flow-control set to "none," but generally none occur.

Only after the entire "binary" file is received does the HP48 take
one more step, unrelated to Kermit, in which it checks to see whether
the received file begins with a specific prefix "HPHP48-x" and if so,
whether all the rest of the received bytes constitutes a valid
internal HP48 binary object; if so, the HP48 delivers the
extracted binary object as its result, and otherwise it leaves
the received string as the result (thus allowing any computer
file to be received literally as a string, even if it does not
represent anything meaningful to the HP48).

As to the version of Kermit supplied by HP, the one I received with
my connection kit (and the only one still found posted on HP's FTP
and web site) responds as follows to the VERSION command:

IBM-PC Kermit-MS: 2.32/A  21 Jan 1989
Copyright (C) Trustees of Columbia University 1982, 1989.

I find this version to work perfectly with the HP48 in an MS-DOS
window under Win 3.1, although other people may report problems
under Win95, possibly due to improper configurations (I can furnish
a list of past postings about such failures and successes, if desired).

In fact, I am using this very Kermit at this very moment, inasmuch as
no other terminal emulator or Telnet program I have yet tried out
emulates the VT-100 as perfectly as does Kermit, and my connection
is via a login to various systems which require a VT-100 emulation.

Congratulations to the Kermit Project for a job long well done,
and even for still caring about the HP48 :)

-----------------------------------------------------------
With best wishes from:   John H Meyers   <[e-mail]>